-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate with wp-product-info for plugin updates #179
Conversation
🦋 Changeset detectedLatest commit: d70b65d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
*/ | ||
function request_plugin_updates( array $args = [] ) { | ||
return wp_remote_get( | ||
'https://wp-product-info.wpesvc.net/v1/plugins/wpgraphql-content-blocks', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The staging endpoint is here: https://wp-product-info-staging.wpesvc.net/v1/plugins/wpgraphql-content-blocks
Copied initial setup from the Atlas Headless Extension plugin.
Our integration with the plugin update mechanism outputs a "active" row to display errors when communicating with wp-product-info. This class is used by WP to style the update notices to match the table row.
This library bootstraps itself and there's no need to save to a variable. Saving to an unused variable causes a phpcs violation.
Turns out we don't need it since we're not packaging the plugin zip.
07ca6f6
to
f615be5
Compare
Revert "chore: update textdomain to wpgraphql-content-blocks" This reverts commit f615be5. Revert "chore: update text domain in phpcs config" This reverts commit 4e94575. Revert "chore: rename zip artifact in release workflow" This reverts commit dbc6071. Revert "chore: rename package name in composer.json" This reverts commit b230797. Revert "chore: update plugin directory name in _lib.sh" This reverts commit 5829908. Revert "chore: update plugin filename in versionPlugin.js" This reverts commit 33c3d6e. Revert "chore: update phpcs config to load renamed plugin file" This reverts commit 075cf94. Revert "test: load renamed plugin file when bootstrapping tests" This reverts commit 1aee962. Revert "chore: Rename main plugin file." This reverts commit 2c9bd3d.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mindctrl Regardless of the testing instructions, at every stage I received the following error:
This happened at all of these stages:
- When I first checked out the branch
- After I updated the staging link
- After I downgraded the version
I made sure to also run composer update
and npm install
. Am I missing anything else?
on: | ||
release: | ||
types: [ published ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I remember correctly, a workflow can not call another workflow without some additional config.
https://docs.github.com/en/actions/using-workflows/reusing-workflows#creating-a-reusable-workflow
Since changesets (another workflow) creates our release, I'm not sure this workflow will get triggered. We experienced this before in the faustjs repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the PR that we dealt with this on Faust. Thankfully it looks like now there is a way to invoke a workflow from a workflow:
When I |
Hi @mindctrl and @blakewilson, I can confirm that I'm seeing the same, across all testing steps. ![]() (The yellow warning box is a symlink tag, and should have that error message at the moment). Additionally, I interpreted the testing instructions as a change to the endpoint, here: ![]() And a change to the version, here: ![]() And then rebuilding at the root of the repo. I expected to see the update notice after this- please let me know if I've missed a step! |
@blakewilson @TeresaGobble thank you for the reviews! If the plugin tried to communicate with the service before you changed it to the staging URL, the error you see will be cached for 5 minutes in a transient. You can delete this transient manually using the Transients Manager plugin. Activate and go to Tools > Transients. I'll take another pass through the code and test things, and will take a closer look at the GitHub Action stuff. |
@mindctrl You are right John. After revisiting I can see all is working as expected now! |
Thank you @mindctrl , I can confirm that after deleting the transient that I see the update notice: ![]() I want to check in about the pipeline deployment- how can I best support you in catching issues with the pipeline? Everything seems to be working well with your example staging, and I don't immediately see any missing data here. |
@blakewilson , I'm still seeing it- was there a change to something locally? How did you check it during this second peek? |
Remove GHA_* parameters from CircleCI config.
branches: | ||
ignore: /.*/ | ||
tags: | ||
only: /^v.*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated all these to run directly in CircleCI when tags are created, instead of using the GHA to trigger Circle. I ran into some known bugs with the Circle trigger action. This also simplifies things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Nice work @mindctrl
Description
Adds the functionality required to get plugin update information from WP Engine's wp-product-info service.
Closes #173
Testing
To test the update functionality against the wp-product-info staging environment from your local machine, you can:
request_plugin_updates()
to point to the staging service (https://wp-product-info-staging.wpesvc.net/v1/plugins/wpgraphql-content-blocks
).Here's a screenshot of an update notice with this installed. Note: this mimics a semver breaking change, so it shows the warning about breaking changes.
To test the pipeline deploy:
Note: the CircleCI pipeline typically only runs when new releases are created in the GitHub repo.
when
conditions from the CircleCI config. Example deploy to staging here: https://app.circleci.com/pipelines/github/wpengine/wp-graphql-content-blocks/53/workflows/3f78c935-9388-43f4-9d59-d89dee43d7fb